[00:06.920 --> 00:15.320]  Kia ora koutou katoa. Welcome everyone. I'm David Robinson, go on the internet as the name carrot.
[00:15.440 --> 00:21.200]  I'm a pen tester at ZX Security in Aotearoa New Zealand. For those who don't know where
[00:21.860 --> 00:24.130]  Aotearoa is, we're at the top of the map there.
[00:26.560 --> 00:33.240]  I enjoy, a little bit about me, I enjoy aviation and hacking. Queensland and Australia has a couple
[00:33.240 --> 00:39.260]  of great conferences with great hacker content, but they're also on their approach path for their
[00:39.260 --> 00:45.000]  local airport so you can sit on the riverbank or on the beach and watch planes come and go.
[00:45.000 --> 00:47.380]  So that's a great combination there.
[00:48.940 --> 00:54.320]  Today we're going to be looking at electronic flight bags in the general aviation cockpit.
[00:54.860 --> 01:00.220]  We're going to go through some example issues, some vulnerabilities, some security type things,
[01:00.220 --> 01:04.880]  and also going to discuss how we can mitigate the issues in each case.
[01:04.880 --> 01:08.560]  I'm going to go through these in more detail as we go through the talk.
[01:11.300 --> 01:15.700]  With the issues I'm going to present, we're at quite a high level for vulnerabilities.
[01:15.740 --> 01:20.540]  Discuss more sort of classes and types of issues, opposed to diving down into
[01:20.540 --> 01:25.620]  individual vulnerabilities. We're not going to be naming vendors or product names here.
[01:25.620 --> 01:30.200]  We're going to try and keep it general so it's helpful for everyone. We're not just sort of
[01:30.200 --> 01:34.640]  giving specific examples. Hopefully there's something that everyone can take away.
[01:36.120 --> 01:41.660]  Sort of for a bit of a framing of the talks of the issues I'm going to present,
[01:41.660 --> 01:45.740]  while I've been thinking about discussing putting this presentation together,
[01:45.740 --> 01:51.240]  I've sort of gone back to the CIA triad and been focusing on their integrity and availability
[01:51.240 --> 01:55.980]  sort of of the systems and how these issues sort of affect those.
[01:57.200 --> 02:03.900]  I will note that a lot of these EFBs and the receivers that are used by EFBs will say,
[02:03.900 --> 02:11.120]  you know, do not use for navigation or safety etc purposes. We know people are actually going
[02:11.120 --> 02:15.640]  to use them. People are going to put too much trust in them. So where possible,
[02:15.640 --> 02:21.820]  we should try and still make them safe if there are people using them in these situations.
[02:24.270 --> 02:30.770]  So what I'd like people to take out of this talk today is some ideas about how to make more robust
[02:30.770 --> 02:36.830]  and secure systems for their customers, for the pilots using their systems. There's going to be
[02:36.950 --> 02:43.510]  a particular focus on general aviation EFBs, but hopefully some of these ideas can apply for
[02:43.510 --> 02:49.410]  other EFB manufacturers and other parts of the aerospace industry.
[02:51.090 --> 02:58.590]  To an IT security professional, most of these issues and problems are going to discuss will not be new issues.
[02:58.590 --> 03:06.970]  I will be trying to put an aerospace spin and examples to them to help tie them to the aerospace industry.
[03:07.390 --> 03:13.750]  But a lot of these issues, as we've seen industries move into a more digital, more connected world,
[03:13.750 --> 03:17.610]  we've seen a lot of these types of issues, categories, classes of issues
[03:17.610 --> 03:23.030]  come up as they've made this transition into this new digital world. So aerospace is not going to be
[03:23.030 --> 03:29.790]  the first industry to go through all these growing pains, nor is it the last industry that is going to
[03:29.790 --> 03:35.490]  go through this growth of product scope and have to deal with these issues.
[03:37.050 --> 03:43.330]  So what is an EFB in the general aviation context? It's often going to be on a tablet.
[03:44.770 --> 03:50.250]  It's going to provide the pilot with some combination of flight charts for navigation,
[03:50.250 --> 03:56.250]  airport charts. It might provide some altitude and heading reference systems.
[03:56.250 --> 04:01.330]  So your artificial horizon, altitude, speed, direction.
[04:02.330 --> 04:08.690]  It may also provide some situational awareness through ADSV or FLAMIN.
[04:08.690 --> 04:15.330]  It will be able to show the pilot what other planes and aircraft are around the plane that
[04:15.330 --> 04:24.490]  they're flying. So this is how a tablet and a receiver and the sensors sort of fit together.
[04:24.890 --> 04:31.930]  So in the middle we have some sort of receiver unit. These are commonly, you know, and then we'll
[04:31.930 --> 04:38.390]  have the tablet with the EFB. And this communication between the receiver and the tablet slash EFB is
[04:38.690 --> 04:42.530]  quite often going to be Wi-Fi. In some cases it's Bluetooth.
[04:43.910 --> 04:49.650]  And between the receiver and the tablet, the most common protocol used is GDL-90.
[04:51.010 --> 04:55.130]  And then some things will also use HTTP or WebSockets.
[04:56.730 --> 05:05.290]  The receiver can take inputs from a variety of different sensors and inputs. So we could have
[05:05.290 --> 05:10.230]  GPS satellites as one with ADSV in to help the situational awareness.
[05:10.230 --> 05:20.170]  We may have a gyro and an accelerometer that will help with pitch, yaw, roll,
[05:20.170 --> 05:28.070]  acceleration, deceleration. In addition to the receiver sending information to the EFB or tablet,
[05:28.070 --> 05:33.030]  there may also be a web interface to the receiver where sort of configuration of the receiver can be
[05:33.030 --> 05:42.150]  done. And this normally happens over HTTP. So for my testing, I sort of only used my own
[05:42.150 --> 05:50.950]  tablets, my own receiver, and my own hardware. Where radio was involved, sort of, I did,
[05:50.950 --> 05:56.990]  you know, I made sure that my signals did stay contained to my test environment. So I used a
[05:56.990 --> 06:02.610]  Faraday cage. Where possible, I turned the transmit power down. I tried to use non-aviation
[06:02.610 --> 06:09.390]  frequencies. So if I could change the frequency used by the transmitter and the receiver unit,
[06:09.390 --> 06:14.390]  I would use non-aviation frequencies. Where possible, I'd directly connect the transmitter
[06:14.390 --> 06:22.090]  to the receiver with a cable and some attenuators to drop. So the receiver wouldn't get burnt out
[06:22.090 --> 06:26.390]  by the additional power. So I was really trying to make sure my system stayed contained
[06:27.330 --> 06:36.240]  to just my test setup. So there's a variety of examples and issues I'm going to go through,
[06:36.240 --> 06:39.320]  and I'm going to go through each one of these in more detail.
[06:43.070 --> 06:46.130]  So first up, we're going to look at heartbeat messages.
[06:47.030 --> 06:53.610]  So what this will do is the receiver will send a heartbeat message on a regular basis. The EFB
[06:53.610 --> 06:57.990]  will receive the heartbeat message and use that as an indication the receiver is up
[06:57.990 --> 07:05.230]  and working as expected. And it can be used to inform the pilot that the receiver is not
[07:05.230 --> 07:11.020]  functioning correctly or the connection between the EFB and the receiver is not working.
[07:12.070 --> 07:19.170]  So as an example, if we start an EFB and the receiver is off, we'll often get some type of
[07:19.170 --> 07:28.550]  red X, some type of no connection, no heartbeat, no connection established,
[07:28.550 --> 07:32.070]  some sort of error message that's quite prominent and displayed. Most of them
[07:32.070 --> 07:36.830]  involved a red X. I was quite clear that the system was not ready for use.
[07:38.250 --> 07:43.070]  So when we did start the receiver and the EFB connected to the receiver,
[07:43.070 --> 07:51.010]  the red X went away and it started to display data. So headings, speeds, altitude, in this case.
[07:53.070 --> 07:58.570]  So what happens when the heartbeat stops? This can be because we turn the receiver off.
[07:58.570 --> 08:03.350]  It could also be because a malicious individual is tampering with the data in some way.
[08:03.690 --> 08:06.130]  So what do people expect is going to happen?
[08:07.030 --> 08:12.890]  Do they expect the EFB to inform the pilot, bring back the red cross?
[08:12.990 --> 08:16.970]  Or do they think everything's just going to continue on hunky-dory?
[08:17.150 --> 08:20.870]  Everything's going to be fine like nothing has happened. It's all OK.
[08:22.650 --> 08:28.550]  So who picked just continue? Well, that is what happened in some cases.
[08:28.970 --> 08:32.470]  When the system is an integrated state, it should tell the pilot that
[08:32.470 --> 08:37.210]  the heartbeat message has gone away, that I can't trust the receiver anymore.
[08:39.430 --> 08:44.950]  So when we are, you know, for these heartbeat messages, we need to make sure the EFB is
[08:44.950 --> 08:49.770]  using it as an ongoing check. It's not just a check to be used to start up,
[08:49.770 --> 08:52.810]  have all the components started up. It needs to be an ongoing check
[08:52.810 --> 08:58.070]  to ensure that the receiver is still up and running. Because in some of these cases,
[08:58.070 --> 09:04.490]  if you stop the receiver, the EFB will keep displaying the same altitude,
[09:04.490 --> 09:10.290]  the same speed, or same location, rather than actually showing that there's an error.
[09:10.570 --> 09:15.590]  So it needs to inform the pilot that, you know, the heartbeat has stopped being received.
[09:15.590 --> 09:19.910]  And you could extend this now to start looking at other data. If you had been continuously
[09:20.490 --> 09:25.130]  receiving the altitude and every message that included the altitude, then suddenly
[09:25.610 --> 09:31.310]  the altitude field was no longer there. That's an indication that, again, that something's wrong,
[09:31.310 --> 09:38.290]  and a piece of data that the EFB was expecting or had become used to expecting has disappeared.
[09:38.290 --> 09:42.190]  Maybe it should inform the pilot that just because the altitude has disappeared,
[09:42.190 --> 09:48.270]  other data may not be as of the high quality as it was before.
[09:54.190 --> 09:57.530]  So the validity of data.
[09:57.850 --> 10:04.710]  The data that EFBs receive from the receivers may not always be valid. Likewise, the data the
[10:04.710 --> 10:11.610]  receivers receive from the sensors or other inputs may also not be correct. Receivers'
[10:11.610 --> 10:17.470]  sensors have faults which could result in bad data being sent. There may be corruption happening
[10:17.470 --> 10:24.410]  on the wire. A malicious individual could be injecting or intentionally manipulating the data
[10:24.410 --> 10:34.280]  to make it malicious. So one example is headings. This is a test I did.
[10:34.600 --> 10:42.520]  Normally a heading in aviation was between 0 and 359 degrees, or 1 and 360 degrees,
[10:42.520 --> 10:47.400]  depending on the particular implementation. But whatever happens, the heading should not be more
[10:47.400 --> 10:58.920]  than 360 degrees. So in one case, with a dummy receiver, I sent an EFB a message where the heading
[10:58.920 --> 11:07.780]  was 450 degrees. It was actually remapped and displayed as 90 degrees, which if you take a
[11:07.780 --> 11:15.140]  step back and you think about the underlying math libraries which EFB may be using, when you talk
[11:15.140 --> 11:22.180]  about degrees and degree maths, 90 degrees makes sense because you've got 450 degrees.
[11:22.180 --> 11:29.940]  So you go 360 for a whole circle, then another 90 degrees, 450. In the math domain,
[11:29.940 --> 11:36.240]  when you're dealing with angles, that makes sense. But in the aviation domain, yes,
[11:36.240 --> 11:44.860]  headings are measured as degrees, but we're dealing with headings, not degrees. So in this case,
[11:51.140 --> 11:57.320]  in aviation, it's 360 degrees. So if it's more than that, we know it's actually an error.
[11:59.620 --> 12:06.560]  So if we take a quick step away from EFBs and we think about another system where
[12:06.560 --> 12:14.000]  there can be pilots presented with information in their user interface, which informs the pilot
[12:14.000 --> 12:19.940]  that there is a disagreement, there is an issue with a sensor. A recent case has been with the
[12:19.940 --> 12:26.520]  737 MAX and the MCAS. One of the things have come out that the angle of attack
[12:27.040 --> 12:33.540]  indicator, the AOA, there's a disagree warning. This was an optional extra that airlines could select.
[12:34.520 --> 12:38.440]  And I understand in the MCAS changes, this warning is now
[12:39.260 --> 12:45.300]  going to be implemented on all 737 MAX aircraft. And what this warning does was
[12:45.300 --> 12:52.920]  displaying that when the sensors no longer, seen as multiple AOA sensors on an aircraft,
[12:52.920 --> 12:57.200]  when the values differed, it was going to warn the pilot there was a disagreement.
[12:57.420 --> 13:02.900]  So the pilots knew that this piece of data could not be no longer valid and maybe they
[13:02.900 --> 13:08.140]  need to use other sources to cross reference and understand what the issue was.
[13:09.380 --> 13:16.460]  So it would be good if AFBs, when they start to detect the data may no longer be valid,
[13:16.460 --> 13:22.060]  it's gone out of bounds, it's not what they expect, there's a disagreement. It'd be good to see if
[13:22.060 --> 13:28.820]  there was a type of warning, you know, if an AFB could provide some sort of warning as the 737 MAX
[13:28.820 --> 13:36.280]  does with AOA disagreement as one sort of recent example. So this can be, you know,
[13:36.280 --> 13:41.440]  when they start to disagree or they go out of bounds, like the headings of the 450 degrees,
[13:41.440 --> 13:44.940]  it's out of bounds, it's an indication there should be an error.
[13:47.220 --> 13:53.620]  So what AFBs and receivers should do is they should know what the data should look like
[13:53.620 --> 14:00.800]  under normal operation. You know, they should be checking that their expected data,
[14:00.800 --> 14:08.920]  is it in the correct range? And when it's out of range, inform the pilots somehow or stop the
[14:08.920 --> 14:14.120]  information being sent so people cannot make the wrong decisions about it. Or you know that
[14:14.120 --> 14:20.640]  you shouldn't be relying on a sensor that is having a fault. Additionally, you can look at the trends
[14:20.640 --> 14:27.600]  in the data. You know, if the vertical speed results in an altitude change that's
[14:27.600 --> 14:32.820]  completely out of bounds, maybe you should stop displaying altitude or vertical speed.
[14:32.820 --> 14:39.080]  So for instance, if your altitude suddenly changes 10,000 feet in a few seconds, either
[14:39.840 --> 14:44.200]  there's a fault with the plane and the pilot already knows about it because the plane is
[14:44.200 --> 14:52.100]  dropping out of the sky, or there is a fault with the receiver or the altitude system somehow.
[14:52.100 --> 14:57.500]  In that case, you should inform the pilot, don't trust this altitude,
[14:57.500 --> 15:03.100]  go trust one of the other instruments that is giving you altitude and rely on that.
[15:03.100 --> 15:09.080]  And it may indicate that other sensors involved, which the EFB users, may also be
[15:09.080 --> 15:20.470]  invalid and the pilot should not rely on them. So with the situational awareness that pilots
[15:20.470 --> 15:24.950]  can have of the aircraft around them, there are some sort of denial of service scenarios.
[15:25.710 --> 15:32.600]  So what some EFBs do is they have a movie map, which is normally for navigation,
[15:33.030 --> 15:36.710]  showing you where the navigational aids are, showing you your route.
[15:38.150 --> 15:44.030]  But additionally, if the system is capable of ADS-B, it can start showing the other aircraft
[15:44.550 --> 15:52.170]  around and where they are. And with software defined radio, it's easy to transmit ADS-B out.
[15:52.170 --> 15:56.770]  RenderMan and others have discussed this previously at many other conferences,
[15:56.770 --> 16:01.570]  and I believe there's some other talks at Aerospace Village on ADS-B spoofing as well.
[16:04.070 --> 16:08.690]  So this is sort of roughly what it looks like. We've got a movie map,
[16:08.690 --> 16:12.150]  we've got the aircraft, we've got its route, and we've got some other planes around it.
[16:14.890 --> 16:18.190]  So what I did was I did a situation where we had this plane and I
[16:18.190 --> 16:24.210]  injected a large number of planes around it. So it's going to be really congested,
[16:24.210 --> 16:31.290]  super congested airspace. Lots of conflicts, lots of potential path crossings, a lot of potential
[16:31.290 --> 16:38.750]  hazards. So when I broadcasted this, I was expecting the EFB to show all the planes that
[16:38.750 --> 16:45.870]  I broadcasted. But in some cases, you know, on the right there in the diagram I've just popped up,
[16:46.690 --> 16:51.810]  it doesn't actually necessarily display all the planes. Some of the planes were being dropped off
[16:52.810 --> 16:59.290]  and missing. It wasn't always the furthest ones away that disappeared, so it wasn't
[16:59.290 --> 17:06.050]  some sort of range thing of there's too many planes. I only showed the closest X number of planes.
[17:07.190 --> 17:12.490]  I couldn't really determine a pattern that resulted that
[17:13.450 --> 17:19.990]  of what planes were missing. And also, if I replayed the same input data into the system,
[17:19.990 --> 17:26.150]  I wouldn't necessarily get the same output. So without sort of further research and diving into
[17:26.150 --> 17:32.910]  the code, my current hypothesis is it's something to do with the way that the timing of the message
[17:32.910 --> 17:40.690]  received and how it packages up X number of planes to send down every half a second or every 10
[17:40.690 --> 17:47.330]  milliseconds, depending on how often it sent the current list of planes, and there was some
[17:47.330 --> 17:52.350]  cut off in buffers. That's my hypothesis. I'm not entirely sure. It's just saw this pattern
[17:52.350 --> 18:01.570]  of indiscriminate planes being dropped off. And this ABSV spoofing that can be combined
[18:01.570 --> 18:08.610]  with TCAS issues. I think Pentest partners, Ken, talked about this back in May. I believe
[18:08.610 --> 18:14.950]  there's also a talk going on during this aerospace village about this in more depth.
[18:14.950 --> 18:24.350]  But what I'll say on this is with ADSV and TCAS, TCAS is the traffic collision avoidance system,
[18:24.350 --> 18:30.590]  that you can actually help. You can start putting in malicious ADSV targets to help
[18:31.170 --> 18:36.590]  reinforce the pilot. There is actually a real TCAS issue. It's not a malicious one,
[18:36.590 --> 18:40.130]  because you can make the two sources correlate with each other. So you could have a malicious
[18:40.130 --> 18:48.030]  plane come in and then you'd start to get TCAS messages maliciously, which will come in and
[18:48.810 --> 18:57.490]  reinforce that as well. So whilst discussing some TCASes, TCAS in some instances from what I understand
[18:57.490 --> 19:03.410]  has directional antennas, so it can tell where the TCAS message is coming from, whether it's to the
[19:03.410 --> 19:10.170]  left or whether it's to the right or up or down and so on. We could do the same with ADSV antennas,
[19:10.170 --> 19:16.650]  so we know where the aircraft should be based on its location in the ADSV message,
[19:16.650 --> 19:22.470]  but we could also look at the direction the signal is coming from to ascertain if
[19:23.190 --> 19:28.110]  I believe the plane's over there and the signal is coming from over there, so that they most
[19:28.110 --> 19:33.690]  probably correspond. But if the plane's over there and the signal is coming from another direction,
[19:33.690 --> 19:40.350]  we know that possibly this is a malicious ADSV message. So if we've got that, we can rule them out.
[19:42.050 --> 19:48.750]  And the ADSV receivers, when they are not going to pass down a full set of aircraft as
[19:48.750 --> 19:55.750]  they're somehow dropping aircraft, it needs to inform the downstream systems, in this case the EFB,
[19:55.750 --> 19:59.610]  that there is an issue and it is operating in a degraded state.
[20:01.930 --> 20:07.830]  Additionally, if the EFB is dropping planes because of some limitation it has,
[20:07.830 --> 20:12.170]  it should also display some indication that planes are missing from the display and
[20:12.170 --> 20:18.090]  do not use this as a situational awareness tool at the moment.
[20:24.960 --> 20:31.020]  So GPS spoofing. From what my testing and from what I've seen,
[20:31.020 --> 20:36.160]  GPS jamming, GPS signal loss are sort of handled quite well in the EFBs.
[20:36.220 --> 20:41.180]  There's normally indicators that there is a GPS fix,
[20:41.180 --> 20:46.980]  and there is also an example when there is no GPS fix, there's an indication.
[20:48.240 --> 20:52.980]  But when we send malicious GPS signals, this is not the case.
[20:52.980 --> 21:00.580]  So when we send a malicious GPS signal, what I'm thinking of is sending a valid GPS signal
[21:00.580 --> 21:07.700]  replicating a set of satellites, which result in the aircraft determining the wrong position.
[21:10.740 --> 21:16.320]  So at last year's Aviation Village, there was a talk on ILS spoofing,
[21:16.320 --> 21:24.600]  which involved in the result of aircraft potentially having the wrong horizontal offsets
[21:24.600 --> 21:32.480]  or the wrong glide slope, and resulting the planes landing in the wrong location.
[21:32.480 --> 21:40.520]  One of the cases here was, oh, GPS and GNSS, RNAV, can be used to cross reference,
[21:40.520 --> 21:45.400]  you know, the glide slope and stuff, so they should be lining up, and if they don't line up,
[21:45.400 --> 21:48.800]  they can alert the pilot, and they can make further decisions about going round
[21:48.800 --> 21:54.040]  and ascertaining what their navigation systems are. But we could also use GPS spoofing
[21:55.880 --> 22:00.560]  to match up with the ILS spoofing, so they're actually going to correspond. This cross check
[22:00.560 --> 22:05.280]  no longer becomes a cross check because they're both incorrect.
[22:05.500 --> 22:08.840]  But they're both incorrect, but they're both showing the same values, so
[22:08.840 --> 22:12.920]  there is no cross check, and there's no indication that one of them is wrong.
[22:15.020 --> 22:20.760]  So back in 2017 at DEF CON, I did a talk where I was doing some GPS spoofing research
[22:20.760 --> 22:25.540]  that was mainly based around time and manipulation of time servers.
[22:25.900 --> 22:32.440]  But what I did during that thing, during that research, was I looked at how we could go about
[22:32.440 --> 22:37.640]  detecting GPS spoofing. And in that case, I came up with a bit of a proof of concept tool
[22:37.640 --> 22:43.460]  called GPS Snitch. It's not production ready, but what it was is looking at some of the GPS
[22:43.460 --> 22:50.100]  parameters, signal parameters, and so it was possible to actually detect when GPS spoofing
[22:50.100 --> 23:00.300]  was happening. So for a start, the maths is all based around the GPS satellites broadcasting
[23:02.340 --> 23:08.300]  a very accurate time, and then based on the time offsets between the different satellites,
[23:08.300 --> 23:10.960]  math happens and you get a location.
[23:12.420 --> 23:19.900]  So if we've got a clock on the receiver that is being synced up with the GPS when we first
[23:19.900 --> 23:27.680]  turned it on, the time should stay in sync together. But if we suddenly start GPS spoofing
[23:27.680 --> 23:34.760]  and the GPS receiver locks onto this spoof set of signals from a range of spoof satellites,
[23:35.540 --> 23:41.600]  we'll notice the time will jump, and it might be 10 milliseconds ahead of time,
[23:41.600 --> 23:48.320]  5 milliseconds slow. But if we get sudden change in time, that's an indication that a spoofing
[23:48.320 --> 23:54.660]  has happened. Because trying to start up and have a spoofing attack start with a time with
[23:54.660 --> 23:59.300]  sub millisecond accuracy is quite a difficult task.
[24:01.260 --> 24:03.920]  And that's one parameter. There's other parameters, and I found
[24:03.920 --> 24:08.240]  that actually when you looked at more parameters, it was actually you get a much more stable
[24:09.420 --> 24:13.140]  system, particularly if you're leaving it running. You know, during my test I left it
[24:13.140 --> 24:18.860]  running for a day just to see what the natural variations were, and I found that sort of one
[24:19.340 --> 24:23.320]  look at one attribute wasn't really enough. You need to look at a range of attributes.
[24:24.680 --> 24:31.380]  So if you're in a case in an aircraft, if the location changes more than what the current
[24:31.380 --> 24:38.460]  speed allows, that's an indication that, you know, it could be GPS spoofing. Because you know your
[24:38.460 --> 24:45.920]  velocity, and if it changes, if you're outside of that, you've got a sort of a circle of uncertainty
[24:45.920 --> 24:52.820]  which may be valid, and if you're outside that, that's a potential issue. Also looking at the
[24:52.820 --> 25:00.960]  GPS signal strength. GPS satellites are 20,000-ish kilometers away, give or take a bit,
[25:00.960 --> 25:05.800]  so the overall strength of the GPS signal when it gets down to ground level is very low.
[25:08.880 --> 25:14.720]  So suddenly if we get a GPS signal suddenly raising strength a lot, that's possibly an
[25:14.720 --> 25:19.300]  indication that a GPS spoofing attack is happening, because the transmitter of the
[25:19.300 --> 25:26.100]  fake GPS satellites is going to be much closer. So matching the signal strength is hard. Additionally,
[25:26.100 --> 25:30.820]  we should have a range of signal strengths, because the satellites directly overhead seem
[25:31.660 --> 25:38.020]  they are closer than the ones way out at the horizon. They're going to have different
[25:38.020 --> 25:42.680]  signal strengths because the distance traveled and the amount of atmosphere they have to travel through.
[25:42.680 --> 25:49.000]  But suddenly if the range of different signal strengths decreases, that's another indication
[25:49.000 --> 25:55.740]  that a malicious GPS transmission is happening, because when you're doing the malicious
[25:55.740 --> 26:00.400]  transmission chances are it's all coming from one transmitter and it's going to have a very
[26:00.400 --> 26:08.750]  similar signal strength. Additionally, like we said back with the TCAS and the GPS was
[26:08.750 --> 26:15.370]  again looking at the signal direction. We know where the GPS satellites should be at any given
[26:15.370 --> 26:23.070]  time. We know the plane's current location. So we know in what direction the GPS signal
[26:23.070 --> 26:28.810]  should be coming from for each of the satellites. So if they don't come from the expected direction,
[26:28.810 --> 26:34.350]  it's an indication that there might be GPS spoofing or a GPS attack happening.
[26:35.930 --> 26:41.750]  So what we need to do to help mitigate some of this risk in the EFBs is they need
[26:41.750 --> 26:46.290]  in the receivers, they need to start monitoring GPS for abnormalities.
[26:47.370 --> 26:50.890]  So like with some of the topics I talked about with the GPS snitch.
[26:51.430 --> 26:56.370]  Show an indicator that when you have no GPS fix, when you detect the spoofing,
[26:56.370 --> 27:04.530]  display GPS no GPS fix because you can no longer trust that as an input. Mark it as no GPS fix
[27:04.530 --> 27:10.050]  or degraded GPS fix or something whatever meets the relevant terminology and
[27:11.130 --> 27:26.020]  accuracy standards. So integrity of the data. The data sort of in the overall system of receivers
[27:26.020 --> 27:32.660]  and EFBs and sensors, it's nearly always happening in clear text. There is an encrypted version of
[27:32.660 --> 27:40.060]  GDL 90, but from what I saw that was not in very common use. My guess is it's a bit of a chicken
[27:40.060 --> 27:46.400]  egg problem. The receiver manufacturers don't see the point in implementing it because none of the
[27:46.400 --> 27:52.940]  receivers, sorry, none of the EFBs are implementing it. EFB manufacturers don't
[27:52.940 --> 27:57.940]  implement it because none of the receiver manufacturers have implemented it.
[27:59.280 --> 28:06.100]  Additionally, the Wi-Fi is often open and in clear text, so anyone within range can connect to it
[28:06.100 --> 28:09.920]  with no authentication required.
[28:13.420 --> 28:20.520]  And also there is when you first sort of pair an EFB and a receiver, there's no key material
[28:20.520 --> 28:27.320]  changed. So you can switch out the receiver and the EFB will still keep talking to it. If it's the same
[28:28.940 --> 28:34.400]  SSID for the Wi-Fi, the same Wi-Fi password, it will just connect fine.
[28:34.400 --> 28:39.460]  It won't inform the pilot. So, you know, think back to your headphones and your phone.
[28:39.480 --> 28:44.420]  When you get a new set of Bluetooth headphones, you need to pair your headphones and your phone
[28:45.400 --> 28:48.480]  and they're connected and they're only going to talk to each other.
[28:48.880 --> 28:53.800]  You know, if you didn't pair them and you didn't have the sort of checking that they're talking
[28:53.800 --> 28:57.540]  to each other, as you're walking down the street listening to music, you'd start hearing the music
[28:57.540 --> 29:04.360]  of everyone walking past you. You know, and we don't want that to happen with our EFB.
[29:04.360 --> 29:09.040]  We want to make sure we're getting the data from our own plane, not our friend's plane.
[29:09.040 --> 29:13.020]  So, you know, if you have a friend who you're doing some formational flying with
[29:13.560 --> 29:17.100]  and because you're friends, you've discussed receivers and you've
[29:17.100 --> 29:21.000]  settled on the same sort of receivers and EFBs because you both like them.
[29:21.720 --> 29:26.560]  You don't want the situation that if everyone's left it with the default Wi-Fis
[29:26.560 --> 29:32.840]  and the default SSIDs because it just starts working, you don't want the EFB in one aircraft
[29:32.840 --> 29:36.620]  connecting to the Wi-Fi in another aircraft around it.
[29:37.460 --> 29:41.440]  Because that's going to be bad if you're receiving data for a different aircraft.
[29:44.380 --> 29:50.480]  So what we should look at here is, where possible, start making the migration to GDL 90.
[29:50.760 --> 29:55.880]  Have receivers start to say, you know, on this date, we're going to implement it. On this date,
[29:55.880 --> 30:01.480]  further down the track, we're only going to have GDL 90. Likewise, on the EFB front, make sure
[30:01.960 --> 30:05.160]  you know your systems are set up to actually accept it.
[30:05.660 --> 30:12.040]  When you first pair an EFB and a receiver, make sure there is some exchange of key material.
[30:12.040 --> 30:19.320]  Make sure there is a pairing process to couple them together so you can't introduce a
[30:19.320 --> 30:25.540]  malicious receiver and have the EFB connect with no error messages.
[30:25.540 --> 30:31.460]  Make sure you sign every message so the EFB can trust that it is coming from a receiver.
[30:31.480 --> 30:36.940]  That it trusts. If the message is not signed, disregard it.
[30:36.940 --> 30:40.360]  And additionally, ensure there's some protection against replay attacks. So
[30:40.980 --> 30:45.600]  make sure that a malicious event that you can't capture a packet or a series of packets
[30:46.400 --> 30:50.380]  and just replay those over and over and over again.
[30:50.680 --> 30:55.100]  Make sure there is some protection that they need to actually keep changing it as it is rolling.
[31:01.040 --> 31:09.420]  So device hardening is part of my job. I look at devices, systems, hardware and to make sure they
[31:09.420 --> 31:13.960]  are robust. You know, there's testing to make sure they've got vulnerabilities, but also checking that
[31:13.960 --> 31:18.260]  they're robust. So even if they're vulnerabilities, I don't know about their attack footprint is as
[31:18.260 --> 31:24.900]  small as possible. And when I was looking at some of those of the receiver devices, I was
[31:25.540 --> 31:31.380]  put this hat on. I was thinking, you know, have they made the attack footprint as small as possible?
[31:32.780 --> 31:38.440]  In some cases, you know, they had made the attack footprint bigger than it could have been.
[31:39.180 --> 31:44.220]  For instance, you know, there was a receiver that had an internal fan and based on the
[31:44.220 --> 31:51.340]  receiver's temperature, it would put the fan speed up and down to keep the system at
[31:51.340 --> 31:57.100]  the optimal temperature. But instead of setting it up so the fan controller only listened to
[31:57.100 --> 32:01.880]  commands coming from inside the device, they configured it so it would accept commands
[32:01.880 --> 32:09.140]  from anywhere in the Wi-Fi network. You know, and that's wrong because in case the only thing
[32:09.140 --> 32:15.700]  the fan controller should be receiving commands from is the temperature sensor inside the receiver.
[32:15.700 --> 32:20.380]  So when the temperature sensor noticed the temperature raising, it needed to tell the fan to
[32:20.380 --> 32:29.100]  go faster and vice versa. Additionally, they're all weak. Wi-Fi configs, as mentioned before,
[32:29.240 --> 32:35.300]  a lot of them are open. They don't have pre-shared keys. They don't use WPA2, WPA3.
[32:37.080 --> 32:39.660]  You know, using pre-shared keys, they will
[32:41.300 --> 32:46.300]  put protection on it. So A, it will encrypt most of the data. B, it will mean that only
[32:46.300 --> 32:50.300]  authorized people can connect to that Wi-Fi network. So you won't have
[32:50.300 --> 32:54.540]  malicious and rogue things connecting to the Wi-Fi network.
[32:55.700 --> 33:02.520]  Though even with the encryption, even with the WPA, WPA2, there's still some attacks you can do
[33:02.520 --> 33:09.780]  against it which can have downsides. For instance, there's management frames which
[33:09.780 --> 33:15.500]  are sort of below the data and control the Wi-Fi connection. And there's a particular
[33:15.500 --> 33:19.840]  message called a deauthentication packet. And what that does, it's sent from the access point
[33:19.840 --> 33:26.420]  to the receiver. So the access point, in this case, would be the receiver device and the
[33:26.420 --> 33:33.320]  wireless client would be the tablet slash EFB. And what the access point says is say, normally you'll
[33:33.320 --> 33:38.980]  say, hey, please disconnect, re-establish, because I want you to re-authenticate.
[33:38.980 --> 33:44.060]  So provide me with the password and whatever again.
[33:44.900 --> 33:48.780]  My problem is, is these messages aren't signed normally. So anyone
[33:49.280 --> 33:55.620]  could come along and send deauthentication packets. And this results in two possible
[33:55.620 --> 34:01.940]  cases that you get a denial of service because the EFB or tablet will no longer be able to connect.
[34:01.940 --> 34:06.940]  It just keeps being told to re-authenticate. So I'll go, I'll connect, get a packet, say
[34:06.940 --> 34:12.240]  re-authenticate, so disconnect, deauthenticate and re-authenticate again.
[34:12.800 --> 34:18.940]  Additionally, it can also be used to steer the device instead of talking to a legitimate receiver.
[34:18.940 --> 34:24.680]  There might be a malicious receiver. So what you do is when it's connected to the legitimate
[34:24.680 --> 34:30.300]  receiver, you send deauthentication packets. When it's connected to the malicious receiver,
[34:30.300 --> 34:35.180]  you don't send deauthentication packets. So it stays connected to that. So the EFB is receiving
[34:35.180 --> 34:42.560]  data from the malicious receiver rather than the receiver that the pilot put there.
[34:43.940 --> 34:51.480]  There's also additional services running. SSH is a common tool used for remote access to a device
[34:51.480 --> 34:59.700]  for configuration. So in essence, production devices don't need SSH enabled at all because
[34:59.700 --> 35:07.000]  they should be in a sort of secure, hardened format. When it's not an active development
[35:07.000 --> 35:14.660]  or active debug, you don't need the sort of access to the device. And even digging into further,
[35:14.660 --> 35:18.920]  its configuration is not in line with sort of best practices for the use case.
[35:18.920 --> 35:24.120]  Sort of in following hardening guides, they sort of had basic things like port 14 turned on,
[35:24.120 --> 35:28.620]  route logons turned on, a lot of things that you wouldn't normally see in something. You'd
[35:28.620 --> 35:33.760]  see it in the default sort of installs just to make it work, but it hasn't shown the additional
[35:33.760 --> 35:42.140]  hardening steps that have gone through. Also, the web config user interface had no password on first
[35:42.140 --> 35:48.400]  use, no password change on first use, no password at all. So even if the Wi-Fi network had a
[35:48.400 --> 35:53.500]  pre-shared key and password, as I mentioned on the previous slide, you should also have
[35:53.500 --> 35:58.040]  a password on the web UI to control the configuration of the receiver. This is so
[35:58.040 --> 36:03.240]  we have security in there, so it's got multiple layers of security control. So if one fails,
[36:03.240 --> 36:09.180]  it's still a safety net to stop it stopping the malicious individual getting further
[36:09.180 --> 36:16.140]  into the system. Make sure you have the safety nets just to make sure things don't happen.
[36:17.980 --> 36:25.280]  So with this is make sure that you seek advice on how to harden the configuration.
[36:25.280 --> 36:31.140]  Make sure their attack footprint is as small as possible. If components have hardening guides,
[36:31.140 --> 36:37.650]  make sure those are read and followed through and used to make the device as secure as possible.
[36:43.230 --> 36:50.330]  So password management. So as I just said, web UIs often didn't have passwords on them or didn't
[36:50.330 --> 36:53.670]  prompt for a password change on first use.
[36:54.450 --> 37:01.650]  Going back to the Wi-Fi case I've used a few times now. There is sometimes options to enable
[37:02.670 --> 37:09.070]  Wi-Fi encryption with WPA2, WPA3 or with pre-shared keys.
[37:09.830 --> 37:18.410]  One when it did this said, came off a message saying we've securely set up your Wi-Fi. You're
[37:18.410 --> 37:24.110]  only going to show you this password the once. If you forget it, you'll need to do a factory reset.
[37:25.550 --> 37:28.850]  So I went through, I factory reset it again.
[37:29.470 --> 37:32.990]  Try setting up the Wi-Fi. Comes up the same password.
[37:34.290 --> 37:42.030]  Go across to a different instance of the same device.
[37:42.550 --> 37:47.450]  Gives me the same password. So instead of being randomly generated, this password was hardcoded.
[37:47.450 --> 37:51.970]  It always gave you the same password to be used for the Wi-Fi.
[37:53.010 --> 37:56.310]  And hardcoded passwords, that is a bad thing.
[37:56.530 --> 38:05.090]  Additionally, in this case, I found it a little bit worse was because the text and the messaging around the password setup
[38:06.510 --> 38:11.850]  gave the user their experience that this was actually going to be a unique password.
[38:11.850 --> 38:14.710]  It was sort of randomly generated.
[38:14.710 --> 38:20.170]  It was secure, when in actual fact it wasn't. And that's sort of a double...
[38:20.170 --> 38:26.950]  makes it sort of doubly bad because the pilot or the user is not actually being provided with the correct information.
[38:26.950 --> 38:31.670]  So they can't make the correct decisions if they've been provided with incorrect
[38:33.170 --> 38:35.610]  input information or documentation.
[38:36.750 --> 38:42.670]  So if there is a hardcoded password that you're going to use, say it's a hardcoded password and recommend that
[38:42.670 --> 38:51.890]  the users actually set their own password. Or better yet, just randomly set a random password.
[38:51.890 --> 38:58.870]  Give them a QR code that you can scan, because most tablets and phones these days can read a QR code with
[38:59.730 --> 39:04.330]  a Wi-Fi password in and set the Wi-Fi up without actually having to type in a long password.
[39:04.330 --> 39:06.110]  You can just scan a QR code.
[39:08.650 --> 39:13.150]  Some of the EFB applications had companion websites.
[39:14.330 --> 39:19.510]  You had to sign up some of the times because the EFBs would not work without them,
[39:19.510 --> 39:27.590]  because they had some sort of subscription functionality that free users...
[39:27.590 --> 39:33.450]  you only saw so much paid users use this, or you had to be a paid user depending on the thing.
[39:33.450 --> 39:38.470]  This allowed for flight plans or additional up-to-date weather information,
[39:38.470 --> 39:46.850]  sort of other non-free services that it gave you. I did not test any of these companion websites.
[39:47.430 --> 39:53.650]  I only went as far as registering an account on these websites.
[39:55.390 --> 40:01.990]  I noticed there were some issues. In one case I got emailed a password in clear text,
[40:01.990 --> 40:08.010]  which to me as a pen tester often means that passwords are not being correctly stored
[40:08.010 --> 40:14.470]  in the database. The fact that a clear text password can be sent via email, so that's a sign
[40:14.470 --> 40:19.730]  that incorrect password storage has been used. Additionally, you also saw some that allowed for
[40:19.730 --> 40:25.590]  weak passwords, so passwords that don't meet the standards of what people think is a strong
[40:25.590 --> 40:31.210]  password these days. Additionally, had some that said, well, don't use any special characters.
[40:31.210 --> 40:37.270]  So putting my pen tester hat on, if I see a password field or some other user input field
[40:37.270 --> 40:43.730]  that says, oh, don't use quote marks, don't use dashes, and don't use these sort of other symbols,
[40:43.730 --> 40:49.190]  to me that's a red flag that SQL injection might be available. They're trying to protect SQL
[40:49.190 --> 40:55.910]  injection by just not allowing users to use these characters. So, you know, if I was testing this
[40:55.910 --> 41:01.470]  for a job at work, if I saw text like don't use the quote mark, first thing I'm going to do is
[41:01.470 --> 41:10.740]  test SQL injection on it because chances are that's why that message is there. So password
[41:10.740 --> 41:18.400]  management. OWASP, the Open Web Application Security Project Foundation, has a range of
[41:18.400 --> 41:24.960]  great check sheets and these uncover password storage, password management, authentication,
[41:25.520 --> 41:31.000]  along with a range of other really helpful documentations. They've got stuff around
[41:31.000 --> 41:36.140]  building more secure web apps. Additionally, they've also got stuff on building secure mobile
[41:36.140 --> 41:41.740]  apps, which most AFBs are. So that's a great resource for information.
[41:43.660 --> 41:50.380]  So hopefully these example issues and solutions have helped you. And you've gone away, you've
[41:50.380 --> 41:55.960]  got some ideas that you want to look into in your own products some more. And I hope that
[41:55.960 --> 42:02.700]  as you do future development, as you add features, as you test functionality, that you think, oh,
[42:02.700 --> 42:07.180]  what could a malicious individual do with this? You know, is there a way that they could affect
[42:07.180 --> 42:13.280]  their integrity or their availability of the system with what they could do? Sort of having
[42:13.280 --> 42:18.100]  the sort of what-if hacker mindset and hopefully you can bring some of that into your testing
[42:18.100 --> 42:26.060]  and your development. Also, what can the security industry do to help the aerospace industry in this
[42:26.060 --> 42:32.000]  regard? What help would you like from us? You know, would some example test cases of this
[42:32.000 --> 42:38.000]  malicious thinking be useful? So as an FB or receiver manufacturer, you can take these
[42:38.000 --> 42:44.560]  test cases on board and start working them into your systems. Would a test harness that
[42:44.560 --> 42:52.200]  was, say, a dummy receiver which talked GDL-90, but instead of just sending sort of valid,
[42:52.200 --> 43:00.080]  helpful GDL-90, also sent malicious payloads and started pushing the boundaries a bit more.
[43:00.080 --> 43:05.560]  Would that be something that was helpful? That you could set up this test harness for this
[43:05.560 --> 43:10.500]  receiver, connect your FB to it and have it send all this malicious information to help you if
[43:10.500 --> 43:15.400]  the automation of the testing. Would that be something that's helped? So really good to hear
[43:15.400 --> 43:23.740]  some feedback from the industry about what you need from us as well. So, thank you. Hopefully
[43:23.740 --> 43:30.700]  it's been useful for everyone. I'd really love to hear feedback, chat to some people, because
[43:30.700 --> 43:34.580]  if I'm passionate about it, I'm sure there are other people here out there who are interested
[43:34.580 --> 43:40.080]  about it. Or that's why you came along and listened to this talk. Thank you very much.
[43:40.220 --> 43:41.480]  See you all later.
